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The  purpose  of  this  study  is  to  examine  the  life  cycle  management  of  Army  Tac- 
tical Management  Information  Systems  with  particular  emphasis  on  integration 
of  the  requirements  of  the  Life  Cycle  System  Management  Model  (LCSMM)  for 
Army  Systems,  DA  Pam  11-25,  and  the  Army  Management  Information  System  (AMIS) 

AR  18-1.  Considerable  attention,  both  in  the  literature  and  in  practice,  has 
been  given  to  the  systems  acquisition  process  for  inception  through  development 
into  production.  The  principal  thrust  of  this  attention,  however,  has  been 
directed  towards  RDTtfE  and  acquisition  of  weapons  systems  to  counter  a perceived 
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EXECUTIVE  SUMMARY 


Purpose  and  Focus  of  the  Study  Project 

Life  cycle  management  of  any  system  is  by  no  means  a simple 
endeavor.  Automatic  Data  Processing  equipment  has  provided  the 
Tactician  and  the  Logistician  a near  "real-time"  means  of  manipulating 
data  and  solving  problems  which  enhances  mission  accomplishment  proba- 
bilities. The  purpose  and  focus  of  this  study  project  is  to  increase 
the  author's  knowledge  of  life  cycle  management  of  Army  Tactical  Manage- 
ment Information  Systems  (TACMIS). 

The  Army  Management  Information  Systems  (AMIS)  Model  does  not 
adequately  define  pre-phase  I activities  and  documentation  require- 
ments. It  also  appears  to  lack  some  definition  in  the  area  of  integrated 
logistics  support  with  respect  to  TACMIS.  This  paper  examines  the  AMIS 
Model  and  compares  It  to  the  Life  Cycle  System  Management  Model  (LCSMM) 
for  Army  systems.  The  purpose  of  this  comparison  is  to  determine  the 
feasibility,  in  gross  overview  terms,  of  modification  and  restructure  of 
the  AMIS  Model  along  the  lines  of  the  LCSMM. 

Material  presented  herein  requires  a working  knowledge  of  the  AMIS 
and  LCSM  models.  In  the  event  the  reader  Is  unfamiliar  with  the  models 
It  Is  recoranended  that  Am\y  Regulation  18-1  and  Department  of  the  Army 
Pamphlet  11-25  be  reviewed  prior  to  reading  this  paper. 
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SECTION  I 
INTRODUCTION 

Purpose  of  the  Study  Project 

Life  cycle  management  of  any  system,  major  or  otherwise,  is 
by  no  means  a simple  endeavor.  Automatic  Data  Processing  Equipment 
(ADPE)  has  provided  the  Tactician  and  Logistician  a near  "real-time" 
means  of  data  manipulation  with  attendant  problem  solving  capabilities 
that  significantly  enhance  mission  accomplishment  probabilities.  Con- 
siderable attention,  both  in  the  literature  and  in  practice,  has  been 
given  to  the  systems  acquisition  process  from  inception  through  develop- 
ment into  production.  The  principal  thrust  of  this  attention,  however, 
has  been  directed  towards  RDT&E  and  acquisition  of  weapons  systems  to 
counter  a perceived  threat.  The  purpose  of  this  study  project  is  to 
increase  the  authors  knowledge  of  life  cycle  management  of  Army  Tactical 
Management  Information  Systems  (TACMIS). 

Specific  Goals  of  the  Project 

The  goals  of  this  project  are  summarized  as  follows: 

1.  Examination  of  the  life  cycle  management  of  TACMIS. 

2.  Comparison  and  integration  of  the  Life  Cycle  System  Management 
Model  (LCSMM)  and  Army  Management  Information  System  (AMIS)  procedures 
and  documentation. 

3.  Determination  of  the  feasibility  of  developing  a Army  TACMIS 
Life  Cycle  Model  (TACMIS-LCM) . 

I 

* 

i 
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Definitions 


1.  Army  Systems  Acquisition  Review  Council  (ASARC) . 

The  ASARC  Is  an  advisory  body  consisting  of  the  VCSA,  ASA(FM) , 
ASA(R&0),  ASA ( I&L ) , DUSO(OR),  ACSFOR,  COA,  DCSRDA , and  DCSLOG.  The 
ASARC  reviews  designated  programs  at  critical  points  during  the 
acquisition  process.  In  general,  the  ASARC  supports  the  overall 
decision  making  process  by  advising  and  recommending  program  decisions 
to  the  Secretary  of  the  Army  and  the  Chief  of  Staff,  US  Army  on: 

1.  Initiation  of  or  change  in  program  commitments  to  include 
transitioning  to  different  acquisition  phases. 

2.  Courses  of  action  in  response  to  an  actual  or  threatened 
breach  of  a program  threshold.  (1:1)1 

2.  Assigned  Responsible  Agency  (ARA): 

The  organizational  element  designated  by  HQDA  to  be  responsible 
for  the  development,  test  and  maintenance  of  a standard  ADP  system.  (2:  A-4) 

3.  Automatic  Data  Processing  System  (ADPS): 

An  aggregation  of  software  and  the  resources  to  support  1t-- 
ADPE,  manpower  and  facilities.  ADPS's  are  associated  with  selected  opera- 
tional levels  which  cut  across  functional  levels  and  include  the 
activities  of  all  DPIs  operating  at  the  selected  level.  (2:  A-4) 

4.  Class  A AMIS: 

a.  All  multiconmand  Management  Information  Systems  (MIS)  except 
Worldwide  Military  Command  and  Control  Systems  (WWMCCS)  and  Intelligence 
Data  Handling  System  (IDHS)  (Al). 

b.  All  command-standard  MIS  operated  at  more  than  one  Data 
Processing  Installation  (DPI)  (Multi-installation  systems)  (A2). 

c.  Amy  elements  of  the  WWMCCS  and  IDHS  (A3). 

d.  All  command-unique  MIS  operated  at  a single  DPI,  where  these 
systems  require  15  man-years  or  more  of  effort  from  initial  concept 
formulation  through  prototype  approval  (A-4). 


This  notation  will  be  used  throughout  the  report  for  sources  of  quota- 
tions and  major  references.  The  first  number  is  the  source  listed  in 
the  bibliography.  The  second  number  is  the  page  In  the  reference. 
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e.  Automated  data  systems  in  support  of  RDT&E  projects  which  require 
15  man-years  or  more  of  effort  from  initial  concept  formulation  through 
Systems  Integration  Test  (SIT)  approval  (A-5)  (2:  1-21). 

5.  Defense  Systems  Acquisition  Review  Council  (DSARC). 

The  DSARC  is  an  advisory  body  consisting  of  DDRE,  ASD ( I&L) , 
ASD(C),  ASD(SA),  and  for  their  programs,  ASD(T)  and  ASD(I).  The 
DSARC  reviews  programs  at  critical  points  during  the  acquisition 
process.  In  general,  the  DSARC  supports  the  overall  decision  making 
process  by  advising  and  recommending  program  decisions  to  the  SECDEF/ 
DEPSECDEF  on: 

a.  Initiation  of  or  change  in  program  commitments  to  include 
transitioning  to  different  acquisition  phases. 

b.  Courses  of  action  in  response  to  an  actual  or  threatened  breach 
of  a program  threshold  (1:1). 

6.  Detailed  Functional  System  Requirement  (DFSR) : 

The  document  used  to  provide  that  level  of  detailed  functional 
guidance  essential  to  the  development  and  maintenance  of  an  ADP  system 
by  the  ARA  and  which  identifies  the  functional  procedures  necessary 
to  develop  the  automated  system  (2:  A-9). 

7.  General  Functional  System  Requirement  (GFSR): 

The  document  used  to  describe  an  automated  management  system 
concept  and  to  provide  a basis  for  initial  determination  of  the 
general  kind  and  degree  of  automation  which- could  be  feasibly  under- 
taken (2:  A-ll). 

8.  Management  Information  Systems  Economic  Analysis  (MISEA): 

A systematic  investigation  of  the  economic/operational  con- 
siderations of  several  competing  alternatives  available,  including  status 
quo,  for  satisfying  a functional  requirement  (2:  2-7). 

9.  Project  Master  Plan  (PMP): 

An  action  plan  which  places  in  context  all  the  plans,  schedules, 
costs,  scopes  of  work,  and  resource  requirements  necessary  to  complete 
the  project  (2:  A-14). 

10.  Proponent  Agency  (PA). 

The  organization/agency  with  responsibility  for  the  particular 
function(s)  which  a management  information  system  automates  (2:  A-14). 
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11.  Tactical  Data  Systems  (TPS): 

An  automated  data  processing  system  which  supports  the  decision 
making  process  for  combat  and  support  functions,  as  opposed  to  direct 
control  of  weaponry,  with  respect  to  battle  field  tactics  and/or  employment 
of  combat  weapons  systems  (2:  A-17). 

12.  Tactical  Management  Information  Systems  ( T ACM IS): 

Multicommand  mobile  environment  standard  Army  Automatic  Data  Pro- 
cessing Systems  (ADPS)  that  provide  combat  service  support  assistance 
(e.g.,  administrative,  logistic,  financial  or  personnel  support)  and  operate 
from  the  Corps  rear  boundary  forward  (7:1). 

Scope  and  Limitations  of  the  Project. 

This  report  encompasses  life  cycle  management  procedures  for  Class 
A Tactical  Army  Management  Information  Systems.  The  principal  thrust 
revolves  around  Automatic  Data  Processing  Systems  (ADPS)  and  computers 
which  are  not  integral  to  a combat  weapons  system.  Classes  B and  C AMIS 
are  excluded  from  direct  coverage  since  these  systems  do  not  involve  aug- 
mentation or  replacement  of  the  computer  mainframe.  The  exclusion  of  these 
systems  Is  not  Intended  to  imply  non-applicability  of  the  materiel  presented. 
It  is  done  only  as  an  expedient  due  to  time  limitations. 


4 


SECTION  II 


BACKGROUND 

Evolution  of  Army  Automated  Data  Systems 

The  US  Army  pioneered  the  development  of  electronic  computers  and 
sponsored  the  first  high-speed  electronic  digital  computer.  The  Electronic 
Numerical  Integrator  and  Calculator  (ENIAC)  was  designed  and  constructed  at 
the  University  of  Pennsylvania  for  the  Ballistic  Research  Laboratories  (BRL), 
Aberdeen  Proving  Ground,  Maryland,  and  was  installed  in  1947.  Subsequent 
efforts  began  in  1955  with  the  preparation  of  a large  number  of  combat 
development  studies.  These  studies  indicated  that  significant  improvement 
could  be  realized  by  the  application  of  ADP  techniques  to  the  combat  tasks 
falling  in  the  general  functional  areas  of  the  four  principal  staff  sections. 
From  these  studies,  requirements  evolved  for  five  ADP  systems  within  the 
Command  Control  Information  System  - 1970  (CCIS-70)  framework.  These 
systems  were  fire  support,  logistics,  personnel  and  administration  operations 
and  intelligence. 

Many  combat  service  support  data  systems  evolved  throughout  CONUS  and 
In  the  overseas  theaters.  Most  of  these  were  installed  to  meet  local  require 
ments  or  to  produce  specialized  information  for  the  Department  of  the  Army 
staff.  As  a result,  there  is  little  compatibility  among  the  systems.  More- 
over, they  possess  only  limited  capability  to  provide  the  information 
required  for  the  planning  and  direction  of  tactical  operations.  Although 
there  had  been  several  years  of  effort  and  activity  in  this  area,  no 
fieldable  system  resulted.  The  Department  of  the  Army  prepared,  and  in 
May  1965  the  Vice  Chief  of  Staff  approved,  the  Automatic  Data  Systems  within 


M* 

•• 

the  Army  In  the  Field  (ADSAF)  study  which  reoriented  the  old  CCIS-70 
effort;  defined  three  related  but  semi -independent  tactical  automatic 
data  systems;  and  established  schedules  and  resource  allocations  for  their 
fielding.  The  three  systems  were  Tactical  Fire  Direction  System  (TACFIRE), 
Tactical  Operations  System  (TOS) , and  the  Combat  Service  Support  System 
(CS3).  (9:2).  A fourth  system.  Missile  Minder  (AN/TSQ-73)  which  is  a 

computer  driven  mobile  air  defense  system,  was  established  In  1968. 

Embedded  Computer  Systems 

An  Increasing  trend  in  the  development  and  acquisition  of  new  military 
weapons  systems  is  the  requirement  for  automated  computational  subsystems 
to  perform  control  functions  and  to  provide  rapid  calculation  and  display 
of  environmental  factors  that  affect  the  mission  of  the  system.  The  new 
terminology  for  these  subsystems  is  embedded  computer  systems  (ECS).  An 
ECS  is  defined  as  "a  computer  system  that  is  Integral  to  an  electro-mechan- 
ical system  such  as  a combat  weapon  system;-  technical  system;  aircraft, 
ship,  missile,  spacecraft,  certain  command  and  control  systems;  and  civilian 
systems  such  as  an  automated  rapid  transit  system."  ECS  are  primarily 
differentiated  from  ADPS  by  how  they  are  developed,  acquired,  and 
operated  in  a using  system  (11:15).  Key  attributes  of  an  ECS  are: 

1.  It  is  physically  Incorporated  into  a larger  system  whose  primary 
function  is  not  data  processing. 

2.  It  Is  integral  to  such  a larger  system  from  a design,  procurement 
and  operations  viewpoint. 

3.  .Its  output  includes  information,  control  signals  and  computer  data 

(11:15). 
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Categories  of  Management  Information  Systems 

The  distinction  between  ECS  and  Non-ECS  has  resulted  In  a different 
acquisition  and  life  cycle  management  process  for  each  type  of  system. 

The  four  systems  previously  mentioned  can  be  placed  In  two  broad  cate- 
gories: 

1.  Tactical  Data  Systems:  Specific  tactical  data  systems  that 

support  combat  and  combat  support  functions  (other  than  logistics  and 
administrative  systems)  are  categorized  as  weapons  systems  for  acquisi- 
tion and  life  cycle  management  purposes.  TOS,  TACFIRE,  and  the  AN/TSQ-73 
are  categorized  as  Tactical  Data  Systems  and  are  managed  by  the  Project 
Manager,  Tactical  Data  Systems  (PM,  ARTADS). 

2.  Tactical  Management  Information  Systems:  Standard  Army  ADPS  that 

provide  combat  service  support  assistance  (administrative,  logistic, 
financial  or  personnel  support)  are  categorized  as  non-weapons  systems. 

This  categorization  is  significant  in  that  it  results  In  the  use  of  differ- 
ent regulations  and  procedures  In  acquisition  and  life  cycle  management. 
Tactical  Management  Information  Systems  are  managed  by  the  Project  Manager, 
Tactical  Management  Information  Systems  (PM,  TACMIS)  and  have  been  expanded 
from  one  to  five  systems.  The  PM,  TACMIS  Is  presently  responsible  for  the 
following  systems: 

a.  Combat  Service  Support  System  (CS3).  The  mobile  division  level 
system  to  Include  ADPE,  Non-ADPE,  and  software  to  support  the  management 
Information  requirements  of  the  Army  division. 

b.  Corps  Automation  Requirements  (CAR).  The  Corps  ADP  support  config- 
uration to  satisfy, reasonably  projected  functional  application  requirements 
of  the  Corps  In  a combat  environment.  CAR  mobile  environment  Includes 
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centralized  and  decentralized  MIS  mobile  ADPE  envisioned  to  satisfy  mid- 
range (3-8  years)  requirements. 

3.  Non-dl visional  Direct  Support  Unit/General  Support  Unit  (DSU/GSU). 

A replacement  system  for  the  current  NCR  500  system. 

♦.  IBM  360/40  Mobile  Corps  Reconfiguration.  The  refurbishment  of  Non- 
ADP  equipment  to  support  the  current  IBM  360/40  Corps  configuration. 

5.  National  Guard/Reserve  Mobile  UNIVAC  1005  System.  The  establishment 
of  the  mobile  UNIVAC  1005  System  and  associated  software  In  the  National 
Guard/Reserve  divisions  and  separate  brigades  (7:1). 
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SECTION  III 

« PRESENT  SYSTEM 

Level  of  Management  Attention 

% 

Army  system  acquisition  from  materiel  concept  Investigation  to  ultimate 
phaseout  and  disposal  of  unneeded  systems  receives  varlng  degrees  of  manage- 
ment attention  depending  upon  the  type  of  system,  weapons  or  otherwise, 
and  the  anticipated  monetary  expenditures  for  RDT&E  and  production.  Tactical 
Data  Systems  are  managed  under  AR  70-1  and  subject  to  Army  Systems  Acquisi- 
tion Review  Council  (ASARC) /Defense  Systems  Acquisition  Review  Council 
(DSARC)  review.  Tactical  Management  Information  Systems  on  the  other  hand 
are  managed  under  AR  18-1  and  are  not  presently  subject  to  ASARC/DSARC 
review. 

TACMIS  Acquisition  Process 

TACMIS  development  activities  during  the  early  stages  are  rather  unique 
with  respect  to  the  TOS  acquisition  process  In  that  AOPE  required  to  support 
the  TACMIS  Is  generally  available  as  off-the-shelf  commercial  hardware. 
Therefore,  the  normal  RDT&E  that  Is  associated  with  the  early  development 
stages  Is  unnecessary.  This  peculiarity  may  account  for  the  fact  that  the 
TACMIS  acquisition  process  Is  not  subject  to  ASARC/DSARC  review.  It  Is 
essentially  possible  to  move  from  the  conceptual  to  the  full-scale  development 
phase  due  to  the  availability  of  off-the-shelf  commercial  ADPE  which,  with 
minor  modification,  will  fully  meet  the  TACMIS  requirements.  As  a result 
of  this  peculiarity  It  appears, to  the  author,  that  a considerable  amount 
of  the  detailed  guidance  and  procedural  aspects  of  early-on  development, 
normally  associated  with  the  systems  acquisition  process,  are  missing. 

This  matter  will  be  explored  In  subsequent  sections. 
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The  AMIS  life-cycle  encompasses  three  separate  and  distinct  phases: 

Phase  I,  Systems  Planning  and  Definition;  Phase  II,  Systems  Development; 

Phase  III,  System  Installation,  Operations  and  Maintenance.  Each  phase 
requires  definitive  and  Increasingly  explicit  systems  documentation,  re- 
view, and  management  (2:  2-3). 

Pre-Phase  I Activities 

Early  Investigations  that  take  place  prior  to  Phase  I should  be 
characterized  by  close,  continuing  dialogue  and  synchronous  Interaction 
between  the  combat  developer  or  designated  sponsor  and  the  materiel 
developer  and  Involve  extensive  efforts  to  expand  the  technology  base 
and  to  use  knowledge  gained  through  exploratory  development  for  poten- 
tial systems  application.  Early  Investigations  are  concluded  when  the 
materiel  developer  and  the  combat  developer  or  designated  sponsor  agree 
that  both  technical  and  operational  potential  exists  for  system-oriented 
advanced  development  or  a determination  has  been  made  by  the  materiel  dev- 
eloper that  the  capability  being  Investigated  exceeds  the  current  state 
of  the  art  or  a determination  has  been  made  by  the  combat  developer  or 
designated  sponsor  that  the  requirement  lacks  operational  relevance  (5:  3-1). 
Subsequent  to  agreement  that  the  requirement  has  operational  relevance  the 
materiel  developer  and  combat  developer  or  designated  sponsor  will  determine 
if  a Letter  of  Agreement  (LOA)  should  be  Initiated.  The  purpose  of  the  LOA 
is  to  Insure  agreement  between  the  combat  developer  and  the  materiel  developer 
on  the  nature  and  characteristics  of  the  proposed  system  and  the  Investiga- 
tions needed  to  develop  and  validate  the  system  concept;  to  define  the 
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associated  operational,  technical  and  logistical  support  concepts;  and 
to  promote  synchronous  Interaction  between  the  combat  developer  or  desig- 
nated sponsor  and  the  materiel  developer  during  the  conduct  of  these  In- 
vestigations (5:  4-0). 

Pre-Phase  I activities  and  procedural  requirements  are  ill-defined  in 
the  present  AMIS  model.  It  does  not  describe  requirements  for  an  oper- 
ational capability  desirable  of  achievement  in  a specified  time  frame;  an 
LOA,  a Required  Operational  Capability,  or  an  Initial  Operational  Capability 
(IOC).  These  areas  are,  of  necessity,  addressed  In  the  actual  development 
of  a TACMIS  even  though  they  are  not  clearly  stated  or  required  by  the  pre- 
sent AMIS  model.  The  present  AMIS  model  indicates  that  a TACMIS  concept 
Investigation  may  be  Initiated  by  subordinate  commands/installatlons  or 
major  Army  commands  (MACOM).  The  results  of  the  Initial  Investigations 
are  submitted  to  the  Proponent  Agency  (PA)  In  the  form  of  a concept  proposal. 
Initial  Identification  of  projected  functional  Information  systems  require- 
ments result  from  the  submission  of  a conceptual  systems  description  by  the 
PA  or  MACOM  to  OAVCSA,  MISD.  This  description  Is  used  as  a basis  for  initial 
development  of  the  General  Functional  System  Requirement  (GFSR)  (2:  2-2). 
Examination  of  the  gestation  of  an  emerging  logistics  system  revealed  the 
following  scenario: 

1.  The  Initial  system  requirement  was  generated  as  a result  of: 

a.  The  use  of  different  data  processing  systems  to  perform  the 
same  logistical  functions. 

•».  Reports  from  the  field  Indicated  that  the  present  system  was 
experiencing  maintenance  problems  due  In  large  measure  to  the  age  of  the 
AOPE. 
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I c.  The  lease  contract  for  the  present  ADPE  was  due  to  expire 

within  two  years. 

2.  The  PA  authorized  the  Initiation  of  an  In-house  study  to  devise  a 
standard  replacement  system.  This  Initial  effort  was  a broad  base  study 
which  Involved  the  Interrelationships  of  supply,  maintenance  and  trans- 
portation. 

3.  Approximately  three  months  later,  the  PA  directed  the  Initiation 
of  a study  which  would  evaluate  current  arid  evolving  supply  systems  and 
recommend  a standard  system  for  Implementation,  If  feasible.  Army  wide. 

The  study  effort  was  to  culminate  with  a final  report  In  the  form  of  a 
6FSR.  A Study  Advisory  Group  (SAG)  was  appointed  and  conducted  the  first 
meeting  approximately  six  months  after  authorization  of  the  Initial  In-house 
study.  A final  SAG  meeting  was  held  approximately  five  months  later  which 
resulted  In  the  approval  of  a draft  General  Functional  Description  (GFD). 

4.  The  final  GFD  was  completed  approximately  13  months  subsequent  to 
authorization  of  the  Initial  In-house  study  (8:  1-3).  Completion  of  the 
final  GFD  terminated  the  Pre-Phase  I activities  for  this  particular  system. 
It  Is  Interesting  to  note  that  the  present  AMIS  model  does  not  provide 
specific  guidance  for  any  of  the  Pre-Phase  I activities  that  occured  In  this 
development  effort.  As  a result  of  this  deficiency  the  PA  imposed  a hydrid 
procedure  on  the  developers  which  was  derived  from  AR  5-5,  The  Army  Study 
System. 

Phase  I - Systems  Planning  and  Definition  Activities 

The  systems  planning  and  definition  phase  encompasses  all  documentation 
and  procedures,  from  concept  formulation  through  requirements  formulation. 
It  provides  for  definition  of  these  concepts  and  requirements  In  terms  of 
specific  systems  objectives.  The  key  documents/products  produced  in  this 
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phase  are  the  General  Functional  System  Requirement  (GFSR),  Management 
Information  System  Economic  Analysis  (MISEA),  Organization  and  Personnel 
Plan  (OPP),  Detailed  Functional  System  Requirement  (DFSR)  Guidance,  Assigned 
Responsible  Agency  (ARA)  assignment,  the  DFSR,  Project  Master  Plan  (PMP) 
Guidance,  PMP  and,  if  required,  recommended  ADPE  specifications.  Activities 
during  this  phase  of  the  TACMIS  acquisition  process  very  closely  parallel 
the  activities  during  the  conceptual  and  validation  phases  of  the  Life 
Cycle  System  Management  Model  for  Amy  Systems  (LCSMM),  DA  Pamphlet  11-25. 
The  following  documentation/decision  point  equivalencies  are  apparent  to  the 
author: 


LCSMM 

TACMIS 

Documentation 

Documentation 

Cost  and  Operational 

Management  Information 

Effectiveness  Analysis 

Systems  Economic  Analysis 

(COEA) 

(MISEA) 

Outline  Development 

GFSR  and  DFSR 

Plan  (OOP) 

Development  Plan  (DP) 

Project  Master  Plan  (PMP) 

Decision  Point 

Decision  Point 

ASARC  I/DSARC  I/DCP  I 

GFSR/MISEA/OPP 

Approval 

Approval 

ASARC  I I/DSARC  I I/DCP  II 

PMP  Approval 

Approval 
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Phase  II  - Systems  Development 

The  systems  development  phase  encompasses  all  documentation  and  pro- 
cedures subsequent  to  approval  of  the  DFSR  through  the  prototype  evaluation. 

It  may  Include  the  procedures  for  acquiring  ADPE  to  support  the  systems 
during  test,  evaluation  and  operational  life.  The  key  documents/products 
produced  In  this  phase  are  the  Project  Guidance  document,  ADP  systems 
specifications,  ADP  system  software  and  documentation,  systems  Integration 
test  report,  systems  development  package,  prototype  evaluation  report  and 
systems  extension  plan.  Also  produced  as  required  are  the  ADPE  guidance 
document  and  documents  supporting  the  selection  and  acquisition  of  ADPE. 

During  this  phase  the  MISEA  Is  again  updated  (2:  2-4).  Activities  during 
this  phase  are  very  similar  to  activities  that  occur  during  the  full  scale 
development  phase  of  the  LCSMM.  For  example,  systems  Integration  testing 
and  prototype  evaluation  generally  occur  during  this  phase. 

Phase  III,  Systems  Installation,  Operations  and  Maintenance 

The  systems  Installation,  operation  and  maintenance  phase  encompasses 
all  procedures  for  installing,  operating,  maintaining  and  modifying  the 
system.  This  phase  starts  with  approval  to  extend  the  system  and  continues 
until  the  system  Is  phased  out  by  a replacement  system  or  otherwise 
terminated  (2:  2-4). 

} 

. 

. 
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SECTION  IV 


TACMIS  LIFE  CYCLE  MODEL 

Methodology 

The  Intent  of  this  section  is  to  identify  areas  In  the  present  AMIS 
LCM  which  appear  to  be  deficient  and  to  establish  the  rationale  for  develop- 
ment of  a detailed  TACMIS  LCM  along  the  same  lines  as  the  LCSMM  contained 
In  DA  Pam  11-25.  The  TACMIS  LCM  suggested  is  of  necessity  a bare  bones 
skeleton  due  to  time  constraints  during  the  preparation  of  this  paper.  This 
model  does,  however,  suggest  definition  and  standardization  of  early  on 
procedural  and  documentation  requirements  and  an  overlay  of  the  LCSMM  on 
the  AMIS  model  with  extraction  of  applicable  activities,  procedures  and 
terminology  to  afford  as  much  standardization  between  the  two  as  possible. 
Standardization  and  definition  of  this  type  is  considered  extremely  impor- 
tant for  the  following  reasons: 

1.  The  present  lack  of  standardization  and  definition  places  a 
requirement  on  system  developers  to  utilize  hybrid  procedures  that  could 
vary  f»*om  system  to  system  thereby  resulting  in  significant  potential  for 

loss  of  lessons  learned  and  corporate  memory. 

2.  Considerable  interest  appears  to  be  mounting  within  OASD(C)  with 
respect  to  Management  Information  System  Life  Cycle  Management  as  evidenced 
by  recent  ADP  policy  memorandums  and  DOD  Instruction  7910.0,  MIS  Life  Cycle 
Management,  (Preliminary  Strawman).  The  principal  thrust  of  this  strawman 
is  the  development  of  the  DOO  MIS  Life  Cycle  which  consists  of  the  following 
phases. 

a.-  Conceptual  Phase  - This  phase  establishes  the  concept  of  the  system 
to  be  automated,  the  benefits  expected,  general  estimates  of  the  cost  of 
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automation  and  a general  plan  for  accomplishing  the  design  and  development 
of  the  system. 

b.  Design  Phase  - This  phase  determines  the  actual  structure  of  the 
system  to  be  automated.  Two  major  design  elements  are  involved;  the  design 
of  the  functional  system  to  the  level  required  to  allow  automation  and  the 
design  of  the  automated  system. 

c.  Development  Phase  - This  phase  results  In  the  production  of  the  ADP 
software,  associated  system  and  user  documentation.  Including  training 
material,  acquisition  of  ADPE  and  support  equipment  as  necessary,  and  test- 
ing of  the  system  parts. 

d.  Integration  Phase  - This  phase  is  required  to  Integrate  all  products 
into  the  system  and  validates  the  system. 

e.  Operations  Phase  - This  phase  controls  the  operation,  maintenance 

and  modifications  to  the  system  from  the  time  it  is  approved  as  an  operational 
system  until  it  Is  terminated. 

f.  Termination  Phase  - System  termination  Is  accomplished  during  this 
phase.  Indications  are,  at  this  point,  that  DOD  components  will  be  required 
to  develop  ADP  Life  Cycle  Management  models  based  upon  the  six  phases  defined 
above  and  in  sufficient  detail  to  allow  specification  of  discrete,  logical 
modules,  sequential  and  concurrent,  which  result  in  identifiable  products 
whose  adequacy  can  be  assessed  and  whose  contribution  to  the  cost  of  the 
system  can  be  specified. 

Present  AMIS  Deficiencies 

The  present  AMIS  model  lacks  sufficient  definition  and  detail  of  Pre- 
Phase  i activities,  procedures  and  documentation  requirements.  The  following 

i 
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areas  are  of  specific  concern: 

1.  The  model  does  not  describe  the  development  of  requirements  for  an 
operational  capability  desirable  of  achievement  In  a specified  time  frame. 

2.  Procedures  for  the  establishment  of  a Study  Advisory  Group  (SAG), 
Special  Task  Force  (STF),  or  Special  Study  Group  (SSG)  are  not  defined. 

3.  Provisions  for  the  development  and  coordination  of  a Letter  of 
Agreement  which  is  extremely  vital  to  the  development  of  a multi -application 
ADPS  are  not  included  in  the  model. 

4.  Procedures  for  the  development  and  coordination  of  a Required 
Operational  Capability  are  not  covered. 

Activities  during  the  Pre-Phase  I and  early  Phase  I periods  are  ex- 
tremely significant  since  the  initial  system  baseline  is  being  developed 
at  this  time.  Logistical  support  planning  during  Phase  I of  the  present 
AMIS  model  appears  to  lack  definition  particularly  with  respect  to  iden- 
tification and  initiation  of  acquisition  planning  for  long  lead  time  items 
such  as  environmental  shields  (tactical  systems  housing  and  support).  The 
model  deals  rather  well  with  each  development  module,  e.g.,  software,  hard- 
ware, but  lacks  in  the  total  Integration  of  these  sub-elements  and  their 
interface  with  non-ADP  requirements  of  the  total  system  development. 

A General  Model 

The  principal  thrust  of  this  paper  is  the  comparison  and  integration  of 
the  present  AMIS  and  LCSM  models.  There  appears  to  be  considerable  overlap 
between  the  two  models  with  a significant  amount  of  applicability  of  the 
LCSW1  to  the  present  AMIS,  particularly  during  the  early  developmental  stages. 
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In  evaluating  the  AMIS  model  with  respect  to  applicability  to  a TACMIS 
there  appears  to  be  a case  for  considerable  modification  along  the  line  of 
LCSMM.  Each  model  is  excellent  for  its  Intended  purpose,  however,  TACMIS 
acquisition  and  life  cycle  requirements  seem  to  fall  conveniently  between 
the  two  models.  An  attempt  to  describe  the  detailed  overlap  and  interface 
requirements  is  beyond  the  scope  of  this  overview.  However,  the  LCSMM  phases 
can  be  superimposed  on  the  AMIS  model  with. critical  decision  points  being 
aligned  as  shown  on  figure  1.  Pre-Phase  I activities  and  Phase  I activities 
of  the  AMIS  model  that  occur  from  concept  proposal  until  approval/disapproval 
of  the  GFSR/MISEA/OPP  closely  correlate  with  the  activities  that  occur 
during  the  Conceptual  Phase  of  the  LCSMM.  Activities  that  occur  subsequent 
to  GFSR/MISEA/OPP  approval  until  PMP/Recommended  ADPE  specifications  correlate 
closely  with  the  activities  that  occur  during  the  validation  phase  of  the 
LCSMM.  As  indicated  by  figure  1,  the  same  correlation  exists  between  Phase  II/ 
Full  Scale  Development  and  Phase  Ill/Production  and  Deployment.  A summary 
of  the  principal  decision  points  Is  as  follows: 


TRANSITION 

Conceptual  to 
Validation 


LCSMM 

ASARC/DSARC  I 


AMIS 

GFSR/MISEA/OPP 

Approval 


Validation  to 

Full  Scale  Development  ASARC/DSARC  II  PMP  Approval 

Full  Scale  Development 

to  Production/Deployment  ASARC/DSARC  III  Extension  Approval 
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SECTION  V 


SUMMARY 

Conclusions 

The  basic  thrust  of  the  LCSMM  and  AMIS  model  is  the  coordinated  and 
systematic  development,  acquisition  and  life  cycle  management  of  a defense 
materiel  system.  No  single  procedure  applies  to  all  materiel  acquisitions. 

The  integration  of  a specific  system  and  the  extent  of  development  may 
vary  from  system  to  system  but  must  be  consistent  with  a general  model  that 
describes  the  acquisition  process.  Several  areas  which  appear  to  be  deficient 
In  the  present  AMIS  model  were  noted  and  are  summarized  as  follows: 

1.  Lack  of  procedural  definition  and  documentation  requirements  during 
the  pre-phase  I period. 

2.  Insufficient  detail  in  the  area  of  logistical  support  planning, 
particularly  during  Phase  I and  II.  Although  the  deficiencies  were  ex- 
pressed in  gross,  general  terms  the  author  considers  the  observations  to 
be  of  sufficient  importance  to  warrant  a more  detailed  investigation. 

The  development  of  a TACMIS  life  cycle  model  closely  resembling  the  LCSMM 
appears  to  be  not  only  feasible  but  highly  desirable.  Such  a development 
effort  would  result  in  the  resolution  of  problems  previously  mentioned  and 
standardization  of  procedures,  documents  and  terminology  in  common  areas. 
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